What is the purpose of this pull request? (put an "X" next to item)

[X] Bug fix: fixes #11510, fixes #11559, fixes #11586
[X] Other, please explain: the refactoring of configurations

Closes #10928 because I realized that this PR does the same thing as #10928 (comment).

What changes did you make? (Give an overview)

This PR fixes three bugs along with the refactoring of configurations.
I'm sorry that this diff is huge.

All new files are in lib/cli-engine/ directory because only CLIEngine uses those.

The refactoring does the following items:

• It simplifies the internal structure of configuration files by an array.
  • The internal structure is expressed by the classes in lib/cli-engine/config-array/ directory.
  • lib/cli-engine/config-array-factory.js creates the internal structure from each config file.
    • This gist is the config array of our .eslintrc.js.
  • lib/cli-engine/cascading-config-array-factory.js handles cascading of config files and CLI options.
• The config object owns loaded plugins and parsers rather than registers those to somewhere.
  • lib/cli-engine/config-array/config-array.js owns loaded plugins and parsers.
  • lib/cli-engine/config-array-factory.js loads plugins and parsers.
  • Linter#getRules() returns the map that contains built-in rules, user-defined rules (by Linter#defineRule()), and plugin rules of ConfigArray instance the last Linter#verify() call used.
  • CLIEngine#getRules() returns the map that contains built-in rules and plugin rules of ConfigArray instances the last CLIEngine#executeOnFiles() or CLIEngine#executeOnText() call used.
• It changes the processing order to "config-then-files" from "files-then-config".
  • lib/cli-engine/file-enumerator.js finds target files by processing glob patterns. While iterating files, it loads the config file of each directory before iterate files on the directory, so we can use the config files to determine target files. (But, it doesn't use the config files to determine target files yet.)

I describe file mapping of before/after the refactoring. There are details for each new file on the top of the source code.

Therefore, appropriate tests to the moved logics are moved to new files.

• Tests in tests/lib/config.js moved to tests/lib/cli-engine/cascading-config-array-factory.js#L88. It's implemented in the CascadingConfigArrayFactory#getConfigArrayForFile() method.

• Tests for applyExtends(), load(), and resolve() in tests/lib/config/config-file.js moved to tests/lib/cli-engine/config-array-factory.js#L1216. It's implemented in the ConfigArrayFactory class.

• Tests for load() and loadAll() in tests/lib/config/plugins.js moved to tests/lib/cli-engine/config-array-factory.js#L2031. It's implemented in the ConfigArrayFactory class.

• Tests for merge() in tests/lib/config/config-ops.js moved to tests/lib/cli-engine/config-array/config-array.js#L349. It's implemented in the ConfigArray#extractConfig() method.

• Tests for pathMatchesGlobs() in tests/lib/config/config-ops.js moved to tests/lib/cli-engine/config-array/override-tester.js#L101. It's implemented in OverrideTester#test() method.

• Tests for listFilesToProcess() in tests/lib/util/glob-utils.js moved to tests/lib/cli-engine/file-enumerator.js#L171. It's implemented in the FileEnumerator#iterateFiles() method.

• Tests for resolveFileGlobPattern() in tests/lib/util/glob-utils.js moved to tests/lib/cli-engine.js#L3412. The new FileEnumerator no longer uses this logic, but it's a public API of CLIEngine. So we have to keep it.

And I added some @typedef comments for VSCode IntelliSense.

Is there anything you'd like reviewers to focus on?

• Are there unintentional breaking changes?

I found an additional breaking change (as a bug fix) about plugin loading. Currently, even if a configuration has no plugins field, CLIEngine#executeOnFiles() and CLIEngine#executeOnText() can use plugin rules that the previous calls loaded. After this PR, CLIEngine#executeOnFiles() and CLIEngine#executeOnText() will report error messages consistently if plugins were not found in configuration.

Related to that, Linter#getRules() and CLIEngine#getRules() will change:

• Linter#getRules() will return the rules, including built-in rules, user-defined rules, and only the plugin rules that the last Linter#verify() loaded.
• CLIEngine#getRules() will return the rules, including built-in rules and only the plugin rules that the last CLIEngine#executeOnFiles() or CLIEngine#executeOnText() loaded.

I think that this change is good because formatters can access to unrelated rules (via RFC 10) before this PR and we already have a getter to get information of the last Linter#verify() call; Linter#getSourceCode().